fix(spec,objectql): declare the inert-JSON artifact and registry-record package body stages, and stop the record under-reporting functions - #19373

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/objectql, @objectstack/spec, touching 18 documentable anchor(s). ⚠️ 9 changed file(s) yielded no anchor (packages/spec/api-surface/automation.json, packages/spec/api-surface/root.json, packages/spec/authorable-defaults/automation.json, …), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

2 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/metadata-service.mdx (via /api/v1/packages/:packageId (route, bridged from symbol installPackage — its route source's handler names it))
• content/docs/protocol/kernel/error-handling.mdx (via /api/v1/packages/:packageId (route, bridged from symbol installPackage — its route source's handler names it))

⛔ 3 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v12.mdx (via installPackage (symbol, a method of class SchemaRegistry))
• content/docs/releases/v17/17-0.mdx (via /api/v1/packages/:packageId (route, bridged from symbol installPackage — its route source's handler names it))
• content/docs/releases/v17/17-4.mdx (via /api/v1/packages/:packageId (route, bridged from symbol installPackage — its route source's handler names it))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8ca4fe8711d721cb5ed90d53a4813376d3205cef && git checkout 8ca4fe8711d721cb5ed90d53a4813376d3205cef
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 97f4f8c8282ebb78de0815cec24eddb8b8335eb0 96dd3549ff68924bcc665fe3209542d44257a6c2 && git checkout -B drift-repro 97f4f8c8282ebb78de0815cec24eddb8b8335eb0 && git merge --no-ff 96dd3549ff68924bcc665fe3209542d44257a6c2

node scripts/docs-audit/affected-docs.mjs --json 97f4f8c8282ebb78de0815cec24eddb8b8335eb0

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 97f4f8c8282ebb78de0815cec24eddb8b8335eb0 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: aac764cc36113b4e52820c1695715f000ccbe1b4

① Derived judgments

Governing ruling, established from the thread rather than the PR body. The card carries four ruling records. 5651572469 (batch #127 item 4, 2026-09-13, maintainer 「其他同意」) prescribed an artifact-stage body BESIDE the assembled one and the read-row rebind. 5716259259 (batch #149 item 1 letter B, 09-17) was presented after a pm:retriage (5706769218 / 5706819210) that did not cite #127, and prescribed the opposite: narrow the assembled body through entry-schema variants. Round R4 measured B as unexecutable (it refuses the in-repo fixture composeStacks builds today, contradicts the 「cannot drift」 invariant, and cannot meet its own acceptance because the inline array member keeps a z.function() handler) and delivered an empty diff by design (Release 5728544298). 5729478920 (batch #159 item 2 letter A, 09-18) restated #127 and WITHDREW B. Round R5 then stalled at A's own step 4: toRecordManifest leaves a residual that is neither a string nor a lowered record, and the producer is packages/objectql/src/registry.ts, outside the surface A drew — second empty diff (Release 5729976367). 5748934194 (batch #192 item 3 letter A′, 2026-09-20, maintainer 「192 同意」) is A plus the mechanism for step 4: a record-stage body with functions[].handler optional, the read rows rebound to THAT stage, and a bare-callable normalisation in objectql at the assembly boundary, ⛔ no minted ref, ⛔ no dropped entry. A′ governs the delivered diff, and the diff executes it step for step. The two places the PR body says it read the ruling rather than transcribed it are judged below.

What @objectstack/spec gains at this head (read from api-surface/, export-origins/, json-schema.manifest/, authorable-*/ and the source, not the PR body): root exports ArtifactStagePackageBodySchema, RecordStagePackageBodySchema and the four …Body / …BodyParsed type aliases; automation exports FlowFunctionLoweredDeclarationSchema with FlowFunctionLoweredDeclaration / …Parsed. json-schema.manifest/automation.json gains automation/FlowFunctionLoweredDeclaration; authorable-surface gains its handler and effect; authorable-defaults records effect = "pure"; the reference docs gain the section and index.mdx counts 1534. declaration-map/automation.json newly maps the AUTHORING FlowFunctionDeclarationSchema to automation/FlowFunctionLoweredDeclaration — that is the generator's documented base-pass rule (it follows the .extend() receiver of an exported def), not a hand edit, and it collides with nothing because the authoring declaration has no def of its own. Nothing exported is lost; the only removal is the module-private AssembledPackageRecordBodySchema const in package-api.zod.ts, which was never exported.

What changes. AssembledInstalledPackageSchema.manifest — the row both ListInstalledPackagesResponse and GetInstalledPackageResponse carry through InstalledPackageAtEitherStageSchema — rebinds from the assembled body with two z.unknown() holes to RecordStagePackageBodySchema. The published JSON Schema of the two responses therefore declares functions and hooks in full (the generated content/docs/references/api/package-api.mdx rows move from any to the lowered shapes). dropped-refinements.baseline.json gains four sites, all …manifest.hooks.element.object: that is HookSchema.object's pre-existing .refine() (hook.zod.ts:220) now reaching the runtime through a declared key while staying out of the JSON output — the ledger doing its job, not a weakened gate.

Is AssembledPackageBodySchema genuinely untouched? Yes, measured two ways. git diff 4b58dcf96..aac764cc3 -- packages/spec/src/stack.zod.ts is one widened import line plus a 142-line pure insertion between the AssembledPackageBodyParsed alias and ArtifactPackageSchema; AssembledPackageBodySchema (1283-1286), assembledPackageBodyShape (1167), composeStacks and the 「cannot drift」 invariant (3974) are byte-identical to the base. Both fenced files (data/hook.zod.ts, migrations/registry.ts) have an empty diff. Executed in an exported copy of this head (never in the clone): compose-stacks-manifest-preserve.test.ts + assembled-package-body.test.ts + the two new or changed spec test files — 4 files / 120 tests green. My own probe: the assembled body accepts a live callable in the map form, the array form and hooks[].handler, and both JSON stages refuse all three.

Do the two stage schemas admit what objectstack build and SchemaRegistry.installPackage really write? packages/cli/src/utils/lower-callables.ts:254-265 writes out[ref] = ref (a bare string) for a bare entry and { ...value, handler: ref } for a declared one; :188-204 lowers hooks[].handler to a string. Probe on the artifact stage: bare ref string accepted, lowered record accepted, callable refused, { effect } residual refused, empty-string ref refused. installPackage has exactly ONE record-writing site (registry.ts:4301, toRecordManifest(withDeclaredFunctionEntries(manifest))), so no update or upgrade path bypasses the normaliser. Probe on the record stage: { effect: 'writes' } accepted, {} accepted and parses to { effect: 'pure' }, array { name, effect? } and { name } accepted, string and lowered record accepted, callables refused. Hooks: a projected hook with neither handler nor body is accepted by all three stages because base HookSchema.handler is already .optional() (hook.zod.ts:252, deprecated in favour of body), so the PR's z.string().optional() inherits that optionality rather than adding it — ruling A′'s 「hooks[].handler a string」 is met. Strictness parity: a map entry with an unknown key is refused by all three stages (the lowered form derives from the strictObject declaration); an ARRAY entry with an unknown key is stripped by all three, because the authoring array member is plain z.object (stack.zod.ts:648) and the transcription matches it — no new tolerance in either direction.

OPEN QUESTION 1 — admitting both lowered spellings. Faithful, and I would have failed the other reading. The ruling's phrase 「functions entries the lowered declaration」 is shorthand for the lowered members of FlowFunctionEntrySchema, which are exactly two (flow-function.zod.ts:265-270: the bare ref string and FlowFunctionLoweredDeclarationSchema); ruling A's step 4, which A′ inherits verbatim, names the legitimate wire shapes as 「a string or a lowered record」. A stage admitting only the record form would refuse every artifact objectstack build writes for a bare function — the class of failure that withdrew B, one key across. Nothing in the tree supports the single-form reading.

Does the objectql change alter what GET /packages serves, and how? Yes, additively. withDeclaredFunctionEntries rewrites a bare callable map entry to { handler: fn, effect: DEFAULT_FLOW_FUNCTION_EFFECT } before the structural projection, which then leaves { effect: 'pure' } — the same value normalizeFlowFunctionEntry assigns a bare callable at boot (flow-function.zod.ts:324), so the record reports what the runtime actually does with the entry, not a minted value. Rows for packages with bare-callable entries gain those keys; nothing is removed; the showcase row goes 1 → 2. The projection's structural rule is untouched, no ref is minted, and the caller's manifest is copied only when an entry was rewritten. No in-repo consumer reads manifest.functions off a registry row (packages/runtime/src/app-plugin.ts:2282 reads the live bundle via resolveArtifactCollections; lit control manifest.objects hits). One asymmetry, not a defect: a bare entry lands as { effect: 'pure' } explicitly, while a declared entry authored without effect lands as {}; both sit inside the record stage, which defaults the latter on parse.

The two ruling items read rather than transcribed, my verdict on each. (a) unemitted-schemas.baseline.json is not edited: its reason line for Automation.FlowFunctionDeclarationSchema says the lowered record 「publishes normally」, which was false while the const was module-local and is true now that automation/FlowFunctionLoweredDeclaration is in the manifest — A′'s correction is achieved by making the sentence true. Acceptable. (b) The package-api.zod.ts docblock's last sentence is corrected in place, and the correction is true: scripts/build-schemas.ts imports the subpath namespaces (../src/kernel, ../src/ui, …) and never ../src/stack.zod, so those two members were never why ArtifactPackageSchema / ObjectStackDefinitionSchema publish no JSON Schema.

One class of row moves from tolerated to refused-by-declaration: a map entry whose effect is neither pure nor writes (reachable only from a defineStack({ strict: false }) host) now fails the record stage where z.unknown() accepted it. That is a producer defect the declaration exists to name, and packages/runtime/src/domains/packages.ts builds its response directly (deps.success({ packages: rows, … })) with no schema parse on the wire, so it changes what the contract says, not what the door does.

② Semver level

The written rule (AGENTS.md 1064-1068 at origin/main): a bug fix in a released package takes patch; the declaration is Clause-②: yes|no with at most one arm; yes takes at least minor; (narrowing) is BREAKING and must carry its FROM → TO migration when it removes or renames anything an author can write. Clause ② itself is defined in .claude/skills/pm-dispatch/references/lanes/spec.md:21-22: widening the accept set or expanding the public surface, however small, is Clause ②; narrowing is still contract surface but does not trigger it, and declaring yes on it is never an error. SKILL.md:515: pulling behaviour back to its declared contract does not touch it.

• @objectstack/spec: minor — correct. Nine new permanently published exports expand the public surface, so Clause-②: yes and at least minor. The read-row narrowing withdraws nothing an author can write: the values it now refuses are a live callable in a JSON row and an invalid effect, neither of which a valid producer emits (measured above on the build output, the projection residual and the array form), so no (narrowing) arm and no migration are owed. This is also exactly the grade ruling 🔗 Broken links detected in documentation #127 item 6 assigned to 「the read API's two keys narrow from anything to their declared shape」.
• @objectstack/objectql: patch — correct under the written rule; this is my reading of OPEN QUESTION 2. No export is added, removed or renamed; the payload gains entries the previous declaration (z.unknown()) already permitted, so no consumer could have relied on their absence; the record is being pulled back to what the package declared and to the record stage, which SKILL.md:515 says is not Clause ②. That is a bug fix in a released package, and the rule assigns it patch. The PR-level Clause-②: yes is satisfied by the spec changeset; the rule does not require every changeset in a yes PR to be minor. Grading it minor would not be an error under lanes/spec.md:22, but it is not what the rule asks for, and ruling A′ asked only that the payload change be declared in the objectql changeset, which it is.

③ Boundary flags

• Published contract semantics moved (handled). The two installed-package read responses now DECLARE manifest.functions and manifest.hooks instead of accepting anything. Every row the door really serves still parses (measured on the build output, the projection residual, the array form and a projected hook), and the door has no runtime response parse, so no runtime refusal that did not exist before is introduced. The four new dropped-refinements sites are recorded by name.
• GET /packages payload change (handled, declared in the objectql changeset). Additive; nothing that was on the wire leaves it.
• Tier H surface, for the maintainer's hand. skills/objectstack-platform/references/_index.md moves one generated line (net 0 tokens, check:skill-refs green). Because the Exports: fallback lists the first five non-constant exports in source order (packages/spec/scripts/lib/export-list.ts, slice(0, 5)), the stack.zod.ts pointer row now names ArtifactStagePackageBodySchema and RecordStagePackageBodySchema and NO LONGER names ArtifactPackageSchema or ObjectStackDefinitionSchema. That is the generator's rule rather than this PR's editing and is not a reason to fail, but it is a visible change to a customer-facing skill index, and the two names that dropped are the file's most consequential exports. A module doc block on stack.zod.ts in a separate change would stop the row depending on export order.
• No security or permission boundary, no migration or retirement shape, no gate weakened. AssembledPackageBodySchema, composeStacks, the drift invariant and both fenced files are untouched.

Measurement notes. The two new schemas carry the structural annotation z.ZodType(Record(string, unknown), Record(string, unknown)) — written here with parentheses in place of angle brackets — the same as the assembled body. Executed locally on an exported copy of this head: 4 spec test files / 120 tests, and a 25-row probe of the three stage schemas with lit and dark controls (z.string() converts, z.object({ a: z.function() }) does not; 55 / 55 / 55 shape members). NOT MEASURED locally: the @objectstack/objectql suite and the runtime conformance files — execution evidence for those is the 42 check runs on this sha (38 success, 4 skipped) read from the API — and the check:generated family, read from the diff and the same check runs.

Implemented-by: claude/issue-17518-assembled-package-body-inert-json
Reviewed-by: session_01LvwGppdonww4zGLWZo5rho

VERDICT: PASS

Generated by Claude Code

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 96dd3549ff68924bcc665fe3209542d44257a6c2

Scope: the DELTA between the previously PASSed head aac764cc361 (comment 5751097514) and this head — one merge of origin/main (7ba5f7f9e6f, 128 commits past merge base 4b58dcf96b3, both parents verified) and one regeneration commit (96dd3549ff6). The feature was reviewed before; this record judges what the merge did to it. Every reading below was taken from the tree, a fresh export of this head with its own dependency install, and the GitHub API — ⛔ not from the round's report, which I read afterwards to compare.

① Derived judgments

The PR's effective diff against main is the same 22 files, and on every both-touched file it is the same change the earlier PASS reviewed. git diff --name-only main..head and git diff --name-only base..aac764cc361 are the identical 22-path set (0 gained, 0 lost). Six of them were also edited by main: content/docs/references/api/package-api.mdx, content/docs/references/index.mdx, packages/spec/dropped-refinements.baseline.json, packages/spec/src/api/package-api.test.ts, packages/spec/src/api/package-api.zod.ts, packages/spec/src/stack.zod.ts. For each I ran a two-direction union proof on the added/removed line multisets — direction A: (head vs this branch's side) must equal (base vs main); direction B: (head vs main) must equal (base vs this branch's side). The three source files and package-api.mdx are IDENTICAL multisets in both directions. So the PR's change to stack.zod.ts against current main is still one widened import plus a pure 142-line insertion (+143/-1), the package-api.zod.ts rebind is still +29/-38 and the test file +64/-7 — byte-for-byte the changes the earlier record judged. Main's own edits to those files are orthogonal: #19595 rewrote the limit/cursor tombstone prose to name the enabled filter, #18319 repaired test fixtures to reverse-domain ids, and #19314 sits at stack.zod.ts line 3426 onward in the declaresCollection/composeStacks region, naming neither functions nor hooks. packages/objectql/src/registry.ts was not touched by main at all.

Finding ① — the second deferred os-regen path. Verified, and the drop was real: at the merge commit the package-api.mdx blob is 988bedaa480, identical to this branch's side and not main's d09cd420711; a grep of the merge-commit revision for main's two contributions (the reverse-domain id description, the enabled tombstone) reads 0 / 0. At this head the same greps read 8 / 2, this branch's declared functions rows read 2, and the dark control (any-typed functions rows) reads 0. The union proof is exact in both directions (+10/-10 and +7/-7). Independently, pnpm --filter @objectstack/spec check:generated on my export of this head exits 0 with check:docs over content/docs/references/** green, so the committed file is what the generator emits from the merged sources. The driver's own docblock (scripts/git-merge-regen.mjs lines 40-46) confirms the mechanism: defer, exit 0, record in os-regen-pending, and the content left behind is OURS by construction. Nothing main landed in that file was lost.

Finding ② — the hand-resolved ledger. Verified as a set operation across base, ours, theirs, merge commit and head. Keys: base 204, ours 204 (0 added, 0 removed), main 205 (api/DatasetSelection added, 0 removed), head 205 = the exact union (0 missing, 0 extra). Per-entry sites reconciled against the expected union (base minus each side's removals plus each side's additions): 0 mismatches over all 205 entries; the four entries this branch adds a manifest.hooks.element.object site to are also four of the entries main repaired, and head carries both edits on each. api/DatasetSelection is present at head and absent from this branch's side, so it arrived from main. Main's fields.out.keyType repair: NINE entries carried such a site at base (the round's narrative said five — a miscount in the prose, not in the file), main removed all nine, head has zero — the removal survived in full. Header: 205 / 565 match the body I counted; refinementSitesThatDidProject was 357 at the merge commit (this branch's stale value) and is 366 at head. I ran pnpm --filter @objectstack/spec gen:schema on my export: exit 0, and it prints 565 refinement site(s) across 205 published schema(s), 366 refinement site(s) DID reach the file, 9 had no JSON form — the four header numbers, re-derived by the instrument that owns them. That run is also the ledger's bidirectional validator (checkDroppedRefinements in scripts/lib/dropped-refinements.ts reports undeclared, miscounted with added/removed/length, repaired and vanished), so its exit 0 means the hand-merged entries equal the observed census path by path. Confirmed the round's design claim: the docblock at line 68 states the ledger is hand-edited with no gen: script by decision, no writer exists anywhere in the tree (git grep over scripts/, packages/spec/scripts/, packages/spec/package.json), and readDroppedRefinementsBaseline never reads measured. ⚠️ Consequence, stated rather than glossed: refinementSitesThatDidProject has no reader and no pin, so nothing in the repo would have caught 357 — the round's own out-of-scope finding is correct and I concur; it is pre-existing, not introduced here.

Finding ③ — the running total 1535. The reasoning holds: base 1533, each side alone 1534, and a union of two disjoint +1 changes must land on 1535, so the two total lines cannot satisfy a single-side-delta test and their disagreement is the signature of a correct union. Measured three independent ways rather than argued: (a) gen:schema on my export prints objectstack.json (1535 definitions); (b) packages/spec/json-schema.manifest/ — a set of sorted lists that git merged as a plain text union with no hand involved — sums to 1533 / 1534 / 1534 / 1535 at base / ours / main / head; (c) the per-module column of the index.mdx table at head sums to 1535 (API 444, Automation 75, Kernel 157, UI 158). On index.mdx the union proof is exact in both directions once those two lines are excluded (+8/-8, +5/-5), and the head lists DatasetSelection, DatasetCompareTo, DatasetTotals, DashboardWidgetChartConfig and FlowFunctionLoweredDeclaration once each while KernelSecurityScanResult and KernelSecurityVulnerability are absent; at the merge commit the control reads 0 DatasetSelection and 1 KernelSecurityScanResult, i.e. main's side really was missing there and is present now.

Both sides' load-bearing names, source AND built dist. Source and ledgers at head: ArtifactStagePackageBodySchema (3 src files, api-surface/root.json, export-origins/root.json), RecordStagePackageBodySchema (4, root, root), FlowFunctionLoweredDeclarationSchema (3, api-surface/automation.json, export-origins, json-schema.manifest/automation.json), DatasetSelectionSchema (5, api-surface/api.json, export-origins, manifest), KernelSecurityScanResultSchema / KernelSecurityVulnerabilitySchema 0 in all three ledgers — with the lit control that both WERE in api-surface/kernel.json and export-origins/kernel.json at the merge base, and the dark control ThisExportWasNeverAuthoredSchema 0 everywhere. Built dist: I built @objectstack/spec on my export (exit 0, 34/34 declaration files, 378/378 references resolved) and probed through the published export map from a workspace package that declares the dependency — 11/11 held: all six present names present in their entries, both retired names undefined, AssembledPackageBodySchema and KernelSecurityPolicySchema present as lit controls, the dark control undefined. The retirement's pin, packages/spec/src/kernel/plugin-security-scan-result-retirement.test.ts, asserts not.toHaveProperty for both retired names on the ./kernel barrel with six surviving neighbours as anti-vacuity, and the only remaining word-level mention of either …Schema name in packages/spec/src is that pin (the other mentions are the migration registry entries and prose). Main's retirement and its guard both survived.

Did the merge withdraw, weaken or alter anything the earlier PASS relied on? No, measured on the built dist of this head: 23/23 behaviour assertions held, with an instrument row (ManifestSchema accepts the fixture), lit and dark controls. The assembled body accepts a live callable and both JSON stages refuse it; both stages accept both lowered spellings; the record stage accepts a handler-less declaration and the artifact stage refuses it; {} parses on the record stage to effect: 'pure'; a string hook handler is accepted and a callable one refused; both JSON stages convert under z.toJSONSchema and the assembled body does not (z.string() lit, z.object({ a: z.function() }) dark); an unknown key is refused by all three. One thing I widened into because main's 128 commits include a BREAKING spec change: #18319 puts a reverse-domain rule on ManifestSchema.id. Both new stages are ManifestSchema.extend(...) derivations, the same construction as the assembled body, so the rule reaches Manifest / Assembled / Artifact / Record identically — measured false/false/false/false on NotReverseDomain, true on a conforming id (lit), false everywhere on an id with a space (dark). The merge did not produce a stage lagging main's change. unemitted-schemas.baseline.json was touched by neither side, so the reason line the earlier PASS relied on is unchanged.

CI on this sha: 42 check runs, 38 success, 4 skipped, 0 other.

② Semver level

The written rule (AGENTS.md, now at lines 1082-1097 on origin/main; the dispatch's 1055-1075 pointer predates main's 17 inserted lines) is byte-identical in that region between the merge base and main, so main brought no change to the grading itself. Because the PR's effective change on every source file is the identical multiset the earlier record graded, the readings stand at this head:

• .changeset/17518-inert-json-package-body-stages.md — @objectstack/spec: minor, still correct. Nine new permanently published exports (present in the dist at this head); Clause-②: yes demands at least minor. No (narrowing) arm is owed by this PR: main's #18319 narrowing of manifest.id reaches the two read responses through ManifestSchema regardless of this PR (the row's manifest was already ManifestSchema.extend(...) with two unknown holes), and it ships under main's own BREAKING changeset with its FROM → TO text — this PR neither adds to nor conceals it.
• .changeset/17518-registry-record-reports-every-function.md — @objectstack/objectql: patch, still correct. registry.ts is untouched by main, so the reasoning of the earlier record (a released read door pulled back to its declared contract, no export added or removed) is unchanged by the delta.

Both changeset files are byte-identical between aac764cc361 and this head, and the Check Changeset runs on this sha are green.

③ Boundary flags

• Published contract semantics, handled and not this PR's own. Because the two JSON stages derive from ManifestSchema, the published JSON Schema of the two installed-package read responses now also carries main's reverse-domain id rule (#18319). It arrives by derivation, applies equally to the assembled body, and is declared in main's breaking changeset; nothing here to fix, but a maintainer reading the regenerated package-api.mdx will see both this PR's functions/hooks rows and main's id rows move in one diff.
• Gate strength, pre-existing gap surfaced by this merge, handled. The ledger's refinementSitesThatDidProject counter sat at 357 in the merge commit while the tree measured 366, and no reader or pin would have caught it; it was corrected by hand from the generator's printed value and my own run confirms 366. No gate is weakened by this PR; the counter was never a gate. The round has filed it.
• No security or permission boundary, no migration or retirement shape introduced by this delta (main's #15932 retirement arrives intact with its pin), no new runtime refusal from the merge: packages/runtime/src/domains/packages.ts still builds its response without a schema parse, and registry.ts is untouched by main.

Measurement notes. Type annotations are written here with PARENTHESES in place of angle brackets: the two new schemas carry z.ZodType(Record(string, unknown), Record(string, unknown)), the same annotation as the assembled body. Executed on a fresh export of this head (never in the clone): gen:schema exit 0, @objectstack/spec build exit 0, check:generated exit 0 (all 15 artifacts up to date against the dist I built), an 11-row dist export probe and a 23-row behaviour probe. NOT MEASURED locally: the @objectstack/spec, @objectstack/objectql and runtime test suites and both typechecks — execution evidence for those is the 42 check runs on this sha (38 success, 4 skipped) plus the round's reported counts, which I did not re-run; the driver-free mergeability of this head against main, for which I have GitHub's mergeable field only.

Implemented-by: claude/issue-17518-assembled-package-body-inert-json
Reviewed-by: session_01LvwGppdonww4zGLWZo5rho

VERDICT: PASS

Generated by Claude Code

Provenance — carriers cleared, landing

Both clause-② carriers were removed by this seat at 2026-09-22T07:43Z, one limb then the other, three seconds apart — a clear, ⛔ not a strip. Each write went through label-write.mjs's four steps and read back:

• card finding(spec): AssembledPackageBodySchema declares callable and custom branches an inert-JSON artifact cannot hold, and every schema embedding it loses its JSON Schema #17518 → bug, priority:p2, pm:dispatched, domain:spec
• PR fix(spec,objectql): declare the inert-JSON artifact and registry-record package body stages, and stop the record under-reporting functions #19373 → documentation, size/l, tests, tooling

Record consumed: comment 5772860458 on this PR — ## Contract review, Served-tier: CONTRACT_REVIEW_TIER, Head-sha: 96dd3549ff68924bcc665fe3209542d44257a6c2, VERDICT: PASS. It is a merge-delta review: the earlier PASS (5751097514) named aac764cc361, and the sixth merge moved the head, so a review naming the landing head was owed and taken.

Tier verified from the reviewing round's own transcript, ⛔ not from the dispatch parameter — counting the harness-stamped per-message served-model field:

⚠️ The two unaccounted occurrences are named rather than rounded away: both are "model":{"description":… inside tool schema definitions, not served-model stamps. 154 of 154 stamps at tier; the arithmetic closes.

The record was adopted verbatim; ⛔ nothing in it was edited.

One number the review corrected, and this seat had propagated

The merge round's prose said main removed the fields.out.keyType sites from five entries. The review measured nine. Re-counted by this seat rather than taking either side:

The FILE was always correct; only the narrative miscounted, and the PR body had inherited it. The body is corrected.

Landing state, all re-taken AFTER the last write

The Tier H gate is lifted, by the register's own terms. Two APPROVED reviews by os-zhuang stand (5262113029, 5262584525). AGENTS.md:273-275, read first-hand:

Tier H … lift only for an authorized APPROVED review by an account in GOVERNED_APPROVERS, on ANY commit and not dismissed; that word is spent once per PR — the OWNING seat then lands it, later pushes included

⇒ both approvals sitting on aac764cc361 (now the pre-merge commit) still count — 「on ANY commit」 — and the sixth merge's push does not re-close the gate — 「later pushes included」. ⛔ This seat submitted no review, under any account.

⚠️ C9 is carried openly into the landing, ⛔ not worked around

--pair cannot reach 0 on this card: two live claim comments by different authors with no Release: between them, the earlier holder being a dev subagent session that ended 2026-09-12 and cannot post. The protocol's two exits are both unavailable, the checker forbids anyone writing that line on a holder's behalf, and the conflict between that prohibition and SKILL.md:496 is filed as #19400. Recorded on the card at 5751042169 and again at 5751467355.

C9 is a claim-bookkeeping row. It is not a carrier row, and Tier H's lift is the approval rather than a --pair zero. This seat is landing on the maintainer's direct instruction — quoted verbatim in 5772269872 — with the row named here rather than left for someone to find.

Next: auto-merge armed SQUASH, then followed to MERGED on origin/main with a lit and a dark control.

Generated by Claude Code